-
Notifications
You must be signed in to change notification settings - Fork 55
Expose single command execute methods #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we just overload the executePs method (with this one taking a string), rather than using a different name?
Same for executeCommand: I'd prefer consistency of naming. If we think that executeScript was not the best name, then we can look at changing that name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should include some javadoc to say what this command does (it's unfortunate that there wasn't any javadoc on the original executePs(List) method).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aledsage
What do you thing about renaming it only for Ps, executePs(String) and executePs(List<String>).
and keep executeCommand(String) and executeCommand(List) for the "Command Prompt" commands? Really we do notexecuteScript` no script was being composed here so I think it is wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, so +1. But let's keep old names as deprecated until Brooklyn catches up.
6921775 to
caa3256
Compare
|
@aledsage can you review it again |
625df2b to
8f8f899
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kind of thing is implementation details rather than part of the contract. I'd therefore be very hesitant about including it in the javadoc.
8f8f899 to
41c3073
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain the reason for the method renames (rather than just overloading the existing methods that have the same behaviour - e.g. executeScript(List) is exactly like this executeCommand(String) if you pass a list of size one).
41c3073 to
e07c19a
Compare
|
Notice it depends on apache/incubator-brooklyn#950 |
a90b9c4 to
fb23919
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although I deprecated it. @neykov has several tests for executePs(List<String>)
|
@neykov can you review it |
|
@bostko I think we should keep the |
57b1dc7 to
29a5a90
Compare
29a5a90 to
82c8990
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wht not create analogous assertExecPs, instead of making compilePs public?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 will change that in my branch of this.
82c8990 to
feb2331
Compare
- moved to a working version of jaxws-maven-plugin - exit codes assertion
feb2331 to
10af906
Compare
|
Closing - I've merged #11 which includes this commit. |
@alasdairhodge , @aledsage Can you review it.
I think it is good to have such methods exposed.
I would even suggest to remove the compileScript but external projects are still dependent on it.